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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 8 March 2004. 



. .Application/Control Number: 09/637,381 p age 
Art Unit: 2177 

( 1) Real Party in Interest 

A statement identifying the real party in interest is contained in the brief. 

( 2) Related Appeals and Interferences 

A statement identifying the related appeals and interferences which will directly 
affect or be directly affected by or have a bearing on the decision in the pending appeal 
is contained in the brief. 

(3) Status of Claims 

The statement of the status of the claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

( 5) Summary of Invention 

The summary of invention contained in the brief is correct. 

(6) Issues 

The appellant's statement of the issues in the brief is correct. 

(7) Grouping of Claims 

Appellant's brief includes a statement that claims 1-24 and 76-81 do not stand or 
fall together and provides reasons as set forth in 37 CFR 1 .192(c)(7) and (c)(8). 

(8) Claims Appealed 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(9) Prior Art of Record 

5,664,153 Farrell, Robert 09-1997 
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5,692,178 


Shaughnessy, Steven T. 


11-1997 


5,761,493 


Blakeley et al. 


06-1998 


6,012,067 


Sarkar, Shyam Sundar 


01-2000 


6,122,640 


Pereira, Hilton M. 


09-2000 


6,202,063 


Benedikt et al. 


03-2001 


6,363,411 


Dugan et al. 


03-2002 


6,390,374 


Carper et al. 


05-2002 


6,424,966 


Meyerzon et al. 


07-2002 


(10) Grounds of Rejection 





The following ground(s) of rejection are applicable to the appealed claims: 
Claims 1-24 and 76-81 are rejected under 35 U.S.C. 102()a). This rejection is 

set forth in prior Office Action, Paper No. 14. A copy of the Final Rejection is as follows: 

Claim Rejections - 35 USC § 103 
1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for 

all obviousness rejections set forth in this and Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
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not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

2. Claims 1 , 9, and 1 7 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Pereira (U.S. Patent No. 6,122,640) and Carper et al. (U.S. Patent 
No. 6,390,374). 

3. Pereira rendered obvious independent claims 1 , 9, and 1 7 by the 
following: 

"...creating a...in-memory database table..." at col. 2, lines 53-56 and col. 9, lines 62-66. 
"...and loading data into the in-memory database table..." at col. 19, lines 43-51 and col. 
9, lines 62-66. 

Pereira does not teach the use of a persistent in-memory table. 

4. However Carper teaches the use of a persistent in-memory table as 
follows: 

"...persistent in-memory... table" at col. 14, lines 41-44. 

It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to persistently store tables in memory in order have rapid access to the data in 
these tables. 

5. Claims 2, 3, 1 0, 1 1 , 1 8, and 1 9 are rejected under 35 U.S.C. 1 03(a) as 
being unpatentable over Pereira and Carper as applied to claims above, and further in 
view of Sarkar (U.S. Patent No. 6,01 2,067). 
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As per claims 2, 10, and 19, the "...data is loaded...," is taught by Pereira at col. 
19, lines 43-51, 

but the "...from a relational data store...," is not taught by either Pereira or Carper. 

However, Sarkar teaches the use of a relational data store as follows: 

*...So far SQL queries are limited to a specific relational 
database with a specific data dictionary (often called the meta 
data repository)..." at col. 5, lines 58-62. 

It would have been obvious to one ordinarily skilled in the art at the time of the 

invention to use a relational data store as a source of data for a database in order to 

use widely used technology for sources of data to gain acceptance for the system. 

6. As per claims 3, 11, and 19, the "...in-memory database table...," is taught 
by Pereira at col. 19, lines 43-51 and col. 9, lines 62-66, 

but the "...is user-defined...," is not taught by either Pereira or Carper. 

However, Sarkar teaches the use of user-defined activities as follows: 

* . . .A user-defined routine (UDR) is a routine that a user 
creates and registers in the system catalog tables and that is 
invoked within a SQL statement or another routine..." at col. 3, 
lines 34-37. 

It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to allow users to define tables in a database in order to provide for user input 
into the design of the database and gain greater acceptance in the user community. 

7. Claims 4, 8, 1 2, 1 6, 20, and 24 are rejected under 35 U.S.C. 1 03(a) as 
being unpatentable over Pereira and Carper as applied to claims above, and further in 
view of Shaunghnessy (U.S. Patent No. 5,692,178). 
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As per claims 4, 12, and 20, the "...to the in-memory database table...," is taught 
by Pereira at col. 19, lines 43-51 and col. 9, lines 62-66, 
but the "...enabling multiple users..." 

and the "...to share access...," are not taught by either Pereira or Carper. 

However, Shaunghnessy teaches the sharing of access to a database by 
multiple users as follows: 

* . . . In this manner, multiple users may transparently access the 
same resources in the same database at the same time, with data 
integrity fully maintained..." at col. 2, lines 31-34. 

*...In contrast to a full lock, a write lock (shared access) 
only prevents other users from changing the contents of a family 
of objects... " at col. 9, lines 55-57. 

It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to allow multiple users to access a database at the same time in order to 
provide for greater utilization of the database resources. 

8. As per claims 8, 16, and 24, the "...to the in-memory database table...," is 
taught by Pereira at col. 19, lines 43-51 and col. 9, lines 62-66, 
but the "...limiting access...," is not taught by either Pereira or Carper. 

However, Shaughnessy teaches the limiting assess to database tables as 



*...It does not, however, limit user access to the objects in 
the family, for example, for viewing a database table... " at 
col. 9, lines 57-58. 



follows: 
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It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to limit the access to database tables in order to permit the viewing or 
modifying of data in the database by unauthorized viewers. 

9. Claims 5, 13, and 21 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Pereira and Carper as applied to claims 1, 9, and 17 above 
respectively, and further in view of Blakeley et al. (U.S. Patent No. 5,761,493). 

As per claims 5, 13, and 21 , the "...dropping the in-memory database table upon 

receipt of a drop table command.. .is not taught by either Pereira or Carper. 

However, Blakeley teaches the use of the drop table command as follows: 

*...SQL commands for data definition in the database are CREATE 
TABLE (specifies a relation schema) , ALTER TABLE (adds an 
attribute to a schema) , and DROP TABLE (deletes a schema) . . at 
col* 1, lines 63-66. 

It would have been obvious to one ordinarily skilled in the art at the time of the 

invention to allow the dropping of a database table in order to provide a means of 

removing a table from the database without disrupting the other tables in the database. 

modifying of data in the database by unauthorized viewers. 

10. Claims 6, 14, and 22 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Pereira and Carper as applied to claims 1, 9, and 17 above 
respectively, and further in view of Blakeley and Meyerzon et al. (U.S. Patent No. 
6,424,966). 

As per claims 6, 14, and 22, the "...dropping the in-memory database table upon 
system shutdown...," is not taught by either Pereira or Carper. 

However, Blakeley teaches the dropping of tables as follows: 



Application/Control Number: 09/637,381 Page 8 

Art Unit: 2177 

'...SQL commands for data definition in the database are CREATE 
TABLE (specifies a relation schema) , ALTER TABLE (adds an 
attribute to a schema), and DROP TABLE (deletes a schema)..." at 
col. 1, lines 63-66. 

It would have been obvious to one ordinarily skilled in the art at the time of the 

invention to allow the dropping of a database table in order to provide a means of 

removing a table from the database without disrupting the other tables in the database. 

modifying of data in the database by unauthorized viewers. 

Blakeley does not teach the use of system shutdowns, 

However, Meyerzon teaches the use of system shutdowns as follows: 

*...The notification source 250 is also responsible for 
requesting an initialization crawl (FIG. 5b) whenever the 
notification source 250 first starts or experiences a 
discontinuity such as a system shutdown..." at col. 10, lines 
28-32. 

It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to drop tables created by users during the current session at the time of 
system shutdown in order to return the table structure of a database to its condition 
before the start of the session. 

1 1 . Claims 7, 1 5, and 23 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Pereira and Carper as applied to claims 1, 9, and 17 above 
respectively, and further in view of Benedikt et al. (U.S. Patent No. 6,202,063). 

As per claims 7, 15, and 23, the "...for creating the in-memory database table...," 
is taught by Pereira at col. 2, lines 53-56 and col. 9, lines 62-66, 
but the "...providing a syntax...," is not taught by either Pereira or Carper. 

However, Benedikt teaches the providing of syntax as follows: 



Application/Control Number: 09/637,381 
Art Unit: 2177 



Page 9 



"...Given the above-described teachings of the invention, an 
illustrative scenario is presented below in the context of FIGS. 
4A and 4B whereby a query pre-processor of the invention 
performs query translation by providing an effective syntax 
query in response to a user- input query including certain 
geometric objects..." at col. 24, lines 33-38. 

It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to provide a syntax in order to provide the users with means of submitting 
queries to the databases. 

12. Claims 76, 78, and 80 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Pereira and Carper as applied to claims 1, 9, and 17 above 
respectively, and further in view of Dugan et al. (U.S. Patent No. 6,363,41 1). 

As per claims 76, 78, and 80, the "...in-memory database table...," is taught by 
Pereira at col. 9, lines 62-66, 

the "...is a persistent in-memory... table..." is taught by Carper at col. 14, lines 41-44, 
the "...database table that remains in memory...," is taught by Pereira at col. 3, lines 47- 
50 and col. 9, lines 62-66, 

the "...of said... in-memory database table...," is taught by Pereira at col. 9, lines 62-66, 

the "...of said persistent in-memory... table..." is taught by Carper at col. 14, lines 41-44, 

but the "...until a user specifies removal...," is not taught by either Pereira or Carper 

However, Dugan teaches the user specified removal of data entities as follows: 

"...If the SLP, SIBB or data status is not active or if data 
dependencies exist, SA ignores the deactivation request and 
notifies the requester,- 4) logging all deactivations of data, 
SLPs and SIBBs; 5) enabling an authorized user to request the 
removal of an SLP, SIBB or data entity and specifying a time for 
a removal; 6) checking the status of the SLP, SIBB or data prior 
to forwarding a removal request to Data Management." 
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It would have been obvious to one ordinarily skilled in the art at the time of the 
invention to store tables in memory until a user specified that the table be removed in 
order provide the user with the control of access to these tables. 

13. Claims 77, 79, and 81 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Pereira and Carper as applied to claims 1, 9, and 17 above 
respectively, and further in view of Farrell (U.S. Patent No. 5,664,153). 

As per claims 77, 79, and 81, the "...in-memory database table.„," is taught by 
Pereira at col. 9, lines 62-66, 

the "...is a persistent in-memory... table...," is taught by Carper at col. 14, lines 41-44, 
the "...database table...," is taught by Pereira at col. 3, lines 47-50, 
the "...accessed by a first user...," is taught by Pereira at col. 11, lines 65-67, 
the "...access by a second user...," is taught by Pereira at col. 1 1 , lines 65-67, 
but the "...the data remains... after it is accessed...," 

and the "...and is available for access...," are not taught by either Pereira or Carper. 

However, Farrell teaches remaining after access and being available for access 
as follows: 

'••.The overhead wasted when these accesses cross a boundary 
from one page to another is quite small compared to the overhead 
saved by correctly leaving the page open after the remaining 
accesses. . /' at col. 15, lines 29-32. 

'...When valid output data is available, access state TCi 466 is 
entered..." at col. 12, lines 17-18. 

It would have been obvious to one ordinarily skilled in the art at the time of the 

invention to persistently have tables remain in memory after access by one user for 
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access by another user in order have rapid access to the data in these tables and not 
waste overhead between accesses of data. 
(11) Response to Argument 

11.1 Applicants 1 arguments filed 8 March 2004 have been fully considered but 

they are not persuasive. In the first argument for independent claims 1 , 9, and 17 on 

page 7, paragraph 3 and page 8, paragraph 1, the applicants state: 

"The reorganization involves unloading row data from the source table held on disk and 
loading the row data into a new table also held on disk (Pereira: col. 8, lines 50-57). To 
facilitate the reorganization, Pereira describes a mapping table mechanism that 
contains pointers to database rows that are being reorganized. However, Pereira does 
not disclose or even suggest that the mapping table contains any data from the tables 
being reorganized. For example, a mapping table is created to map rowids of the source 
table to rowids of the rows inserted into the new table (Id.). Once the reorganization is 
complete, the new table becomes the source table and the original source table is 
dropped (Pereira: Abstract). Thus, the mapping table is a temporary product of the 
reorganization process and does not even contain the data being reorganized but 
instead contains only pointers to database rows." 

The Examiner disagrees. Pereira teaches the storing of the mapping table in a database 
as a database table. The only requirement as to what data is stored in a database table 
is that that the types of data stored correspond to the types of data that are allowed in 
specified fields in tables. 

1 1 .2 In the second argument for independent claims 1 , 9, and 1 7 on page 8, 
paragraph 2, the applicants state: 

"Pereira discloses that the mapping table can be stored in several different locations, 
such as in a file, in a database management system (DBMS), or in memory (Pereira: 
col, 9, lines 62-66). Although Pereira discloses that the mapping table can be stored in 
database management system (DBMS), Pereira does not teach or suggest that the 
mapping table must be stored in the form of a table in the DMBS (Pereira: col. 9, lines 
58-67). And while Pereira discloses that the mapping table can be stored in memory, 
Pereira neither teaches nor suggests that when storing the mapping table in memory 
that it is stored in a database table held in memory. On the contrary, Pereira considers a 
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database table as a different type of storage than memory since it lists each as a 
separate location where the mapping table can be stored (Id.). 

The Examiner disagrees. The applicants are making an assumption that information for 

a mapping table stored in a database will be different than information for a mapping 

table stored in memory. There is no data to support this assumption. It is more likely, 

that the information is the same regardless of where it is stored. It is reasonable to 

conclude that the same information in the same formats may be stored either in a 

database or in memory. 

1 1 .3 In the third argument for independent claims 1 , 9, and 1 7 on page 9, 

paragraph 5 and page 10, paragraph 1, the applicants state: 

"The Examiner appears to be confusing Pereira's disclosure of a conventional database 
table, which is disclosed only as holding data and being stored in secondary storage, 
such as on a magnetic disk (Pereira: col. 2, lines 53-56; see also col. 1, lines 41-48), 
with Pereira's disclosure of a mapping table, which is disclosed as only holding pointers 
to the rows in the database tables (Pereira: col. 9, lines 62-66). In Pereira, while blocks 
from a source table held on disk, which is being reorganized, may be temporarily held in 
memory until they are inserted into a new table also held on disk, these blocks of data 
do not represent an in-memory database table but instead are pieces of data (from a 
source database table held on disk) to be ordered and inserted into a new database 
table held on disk (Pereira: Table 6; see also col. 1 , lines 41-57)." 

The Examiner disagrees. When a database table is defined, the definition applies both 

to the portion stored on disk and the portion stored in memory. A database table solely 

on disk would be unworkable because inserts, deletes, and modifications of individual 

rows could not be made. During an operating session, a portion of the table is in 

memory where it can easily accommodate the inserts, deletes, and modifications of 

individual rows and at specified times during the processing the portion of the databse 

in memory is written back to disk. 
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1 1 .4 In the fourth argument for independent claims 1 , 9 f and 1 7 on page 1 0, 
paragraph 4 and page 11, paragraph 1, the applicants state: 

"Further still, the Examiner asserts without any support that a table that may be stored 
in the DBMS is clearly a database table (Office Action: page 10). Based on this 
unsupported assertion, the Examiner then alleges that since Pereira describes that the 
mapping table may also be stored in memory, Pereira teaches "an in-memory database 
table". Appellants respectfully disagree. Pereira merely lists places where the mapping 
table can be stored, such as in a DBMS, or in a file system or in memory ("the mapping 
can be stored in the form of a table in the DBMS, in memory, on a file system or [by] 
any other method in which the mapping table may be maintained and later used by the 
reorganization process") (Pereira: col. 9, lines 58-67)." 

The Examiner disagrees. Pereira teaches the use of an in-memory database table as 
follows: 

*...The mapping table is utilized to process deletions of 
specific rows, if needed, in the latter half of the 
reorganization process. The mapping can be stored in the form of 
a table in the DBMS, in memory, on a file system, or any other 
method in which the mapping table may be maintained and later 
used by the reorganization process..." at col. 9, lines 60-66. 

Clearly, a table that may be stored in a DBMS qualifies as a database table. Likewise, a 

table the may be stored in memory qualifies as an in-memory table. Since the mapping 

table is both a database table and an in-memory table, it qualifies as an in-memory 

database table. 

1 1 .5 In the fifth argument for independent claims 1 , 9, and 1 7 on page 1 1 , 
paragraph 2, the applicants state: 

"In general, a DBMS will store database tables on a random access storage device, 
such as a magnetic disk drive, and not in memory, so to achieve semi-permanent 
storage (Specification: page 1, lines 26-28). Indeed, Pereira likewise refers to persistent 
storage as a disk (Pereira: col. 12, lines 9-10)." 
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The Examiner disagrees. Permanent memory is persistent memory. Pereira teaches the 
use of persistent memory as follows: 



* . . . In Oracle, a system checkpoint assures that all dirty blocks 
are written to persistent storage (disk)../' at col. 12, lines 
9-10. 

The definition of "persistent memory" provided by Pereira is consistent with the 
recognized definition of "persistent memory" at the time of the priority date of the 
proposed invention. The "Microsoft Press Computer Dictionary", 3 rd edition, copyright 
1997 states that persistent data is "data that is stored in a database or on tape so that it 
is retained by the computer between sessions." 

1 1 .6 In the sixth argument for independent claims 1, 9, and 17 on page 12, 
paragraph 2, the applicants state: 

"To the contrary, the command table of Carper, like the mapping table of Pereira, is not 
a database table. Instead, the command table serves to identify commands executable 
by a new application installed on a smart card (Id.). Thus, when a command is received 
in the operating system, the operating system uses the command table(s) stored in 
memory in an attempt to identify an application able to execute the command (Id.)." 

The Examiner disagrees. Carper teaches the use of persistent tables stored in memory 

as follows: 

*...This is done by reference to the one or more command tables 
stored in memory. Like all persistent data objects and files in 
memory, each command table must be referenced in a file 
directory..." at col. 14, lines 60-64. 

The persistent in-memory tables of Carper when combined with the in-memory 
database of Pereira provide in-memory persistent database tables. 
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1 1 .7 In the seventh argument for independent claims 1 , 9, and 1 7 on page 1 2, 
paragraph 3, the applicants state: 

"Additionally, the Examiner fails to provide any reasonable suggestion or motivation, 
absent impermissible hindsight, for combining the references. Appellants note that to 
establish a prima facie case of obviousness, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available 
to one of ordinary skill in the art, to modify the reference or to combine reference 
teachings (see MPEP § 2143)." 

The Examiner disagrees. It would have been obvious to one ordinarily skilled in the art 
at the time of the invention to combine Pereira and Carper to persistently store tables in 
memory in order have rapid access to the data in these tables. Database tables stored 
only on disk would be unworkable because inserts, deletes, and modifications of 
individual rows could not be made and input/output access to memory is much faster 
than access to disks. 

11.8 In the eighth argument for claims 2, 3, 1, 11, 18, and 19 on page 14, 

paragraph 5 and page 15, paragraph 1, the applicants state: 

"In rejecting claims 2-3, 10-11 and 18-19 under 35 U.S.C. § 103(a), the Examiner relies 
on a combination of Pereira and Carper, as applied to claims 1, 9 and 17, and further in 
view of Sarkar. However, Appellants respectfully submit that Sarkar fails to cure the 
exemplary deficiencies of Pereira and Carper, as set forth above in Section Vlll(1), for 
claims 1, 9 and 17. Consequently, claims 2-3, 10-11 and 18-19 are patentable over a 
reasonable combination, if any, of Pereira, Carper and Sarkar, at least by virtue of their 
dependency, as well as the additional features set forth below. Furthermore, for at least 
the reasons set forth above in Section Vlll(1) for claims 1, 9 and 17, and in addition to 
the disparate teachings of Sarkar, Appellants submit that the Examiner fails to provide 
any reasonable suggestion or motivation, absent impermissible hindsight, for combining 
Pereira, Carper and Sarkar in the manner proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1, 9, and 17. Since the 
responses to the first seven arguments have established that the combination of Pereira 
and Carper has rendered obvious the independent claims 1, 9, and 17 and there is no 
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additional requirement for Sarkar to render obvious these independent claims. It would 
have been obvious to one ordinarily skilled in the art at the time of the invention to use a 
relational data store as a source of data for a database in order to use widely used 
technology for sources of data to gain acceptance for the system. Likewise, it would 
have been obvious to one ordinarily skilled in the art at the time of the invention to allow 
users to define tables in a database in order to provide for user input into the design of 
the database and gain greater acceptance in the user community. The use of a 
relational data store to store a database is an inherent property of relational databases 
as is the practice of allowing users to define database tables. Since no additional 
arguments have been provided for claims 2, 10, and 18, their dependency on 
independent claims 1, 9, and 17 still renders these claims obvious. 

11.9 In the ninth argument for claims 2, 3, 10, 11, 18, and 19 on page 15, 
paragraph 4 and page 16, paragraph 1, the applicants state: 

"In particular, the Examiner alleges that Sarkar teaches a "an in-memory database table 
[that] is user-defined" by describing user-defined routines (citing Sarkar: col. 3, lines 34- 
37). To the contrary, as noted above, Sarkar merely describes a database server that 
supports user-defined routines (UDRs), such as a function or a procedure written in a 
high level programming language (Sarkar: col. 3, lines 15-18 and 33-45).. These 
routines are created by users and are registered in the system such that they can be 
invoked within an SQL statement or another routine (Sarkar: col. 3, lines 33-45). For 
example a user can create a function x that takes a set of arguments and returns a set 
of values, such that the function can be used in an SQL expression (Id.). This ability to 
support user-defined functions and procedures does not teach or suggest allowing a 
user to define an in-memory database, (see claims 3, 1 1 and 19)." 

The Examiner disagrees. Sarkar teaches the defining of a database schema by a user 

and hence the defining of a database as follows: 

* • . -A schema in a typical universal server is shown in FIG. 2 
where two tables are defined as R (A, B) and S (C, D, E) . Table 
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S inherits the primary key B from R as foreign key in attribute 
D. Attribute E of table S is a non- simple type defined by the 
user. These user defined types are usually associated with an 
object or package containing method and operator definitions. 
Example of such an user defined type in one of the available 
universal servers is given below..." at col. 7, lines 10-17. 

The defining of database by users is an inherent property of relational databases. The 

teachings of Sarkar are entirely consistent with this inherent property of databases. 

Claims 3, 1 1 , and 19 are still rendered obvious due to their dependency on independent 

claims 1, 9, and 17. 

11.10 In the tenth argument for claims 4, 8, 1 2, 1 6, 20, and 24 on page 1 6, 

paragraph 3, the applicants state: 

"In rejecting claims 4, 8, 12, 16, 20 and 24 under 35 U.S.C. § 103(a), the Examiner 
relies on a combination of Pereira and Carper, as and further in view of Shaughnessy. 
However, Appellants respectfully submit that Shaughness,y fails to cure the exemplary 
deficiencies of Pereira and Carper, as set forth above in Section Vlll(1), for claims 1, 9 
and 17. Consequently, claims 4, 8, 12, 16, 20 and 24 are patentable over a reasonable 
combination, if any, of Pereira, Carper and Shaughnessy, at least by virtue of their 
dependency. Furthermore, for at least the reasons set forth above in Section Vlll(1 ) for 
claims 1 , 9 and 17, and in addition to the disparate teachings of Shaughnessy, 
Appellants submit that the Examiner fails to provide any reasonable suggestion or 
motivation, absent impermissible hindsight, for combining Pereira, Carper and 
Shaughnessy in the manner proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1 , 9, and 17. Since the 
responses to the first seven arguments have established that the combination of Pereira 
and Carper has rendered obvious the independent claims 1 , 9, and 17, there is no 
additional requirement for Shaughnessy to render obvious these independent claims. 
It would have been obvious to one ordinarily skilled in the art at the time of the invention 
to allow multiple users to access a database at the same time in order to provide for 
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greater utilization of the database resources. Likewise, it would have been obvious to 
one ordinarily skilled in the art at the time of the invention to limit the access to database 
tables in order to permit the viewing or modifying of data in the database by 
unauthorized viewers. The allowing of access to databases by multiple users in order to 
modify the database as long as the modifications are independent from one another is 
an inherent feature of rational databases. Likewise, the allowing of access to databases 
for viewing only is an inherent feature of rational databases. Since no arguments for 
claims 4, 8, 12, 16, 20, and 24 have been provided other than their dependence on 
independent claims 1 , 9, and 1 7, these claims are still rendered obvious, 

11.11 In the eleventh argument for claims 5, 13, and 21 on page 17, 
paragraph 2, the applicants state: 

"In rejecting claims 5, 13 and 21 under 35 U.S.C. § 103(a), the Examiner relies on a 
combination of Pereira and Carper, as and further in view of Blakeley. However, 
Appellants respectfully submit that Blakeley fails to cure the exemplary deficiencies of 
Pereira and Carper, as set forth above in Section Vlll(1), for claims 1, 9 and 17. 
Consequently, claims 5, 13 and 21 are patentable over a reasonable combination, if 
any, of Pereira, Carper and Blakeley, at least by virtue of their dependency. 
Furthermore, for at least the reasons set forth above in Section Vlll(1 ) for claims 1 , 9 
and 17, and in addition to the disparate teachings of Blakeley, Appellants submit that 
the Examiner fails to provide any reasonable suggestion or motivation, absent 
impermissible hindsight, for combining Pereira, Carper and Blakeley in the manner 
proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1, 9, and 17. Since the 
responses to the first five arguments have established that the combination of Pereira 
and Carper has rendered obvious the independent claims 1, 9, and 17, there is no 
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additional requirement for Blakeley to render obvious these independent claims. Pereira 
teaches the dropping of tables as follows: 

* . . .After switching the source table with the reorganized table, 
the original source table may be dropped making space available 
for new or other tables..." at col. 4, lines 7-9. 

Since Pereira already teaches the dropping of tables there is no requirement for the 

Blakeley reference. Since no arguments for claims 5, 13, and 21 have been provided 

other than their dependence on independent claims 1, 9, and 17, these claims are still 

rendered obvious, 

1 1 .12 In the twelfth argument for claims 6, 14, and 22 on page 17, paragraph 4 
and page 18, paragraph 1, the applicants state: 

"In rejecting claims 6, 14 and 22 under 35 U.S.C. § 103(a), the Examiner relies on a 
combination of Pereira and Carper, as applied to claims 1 , 9 and 17, and further in view 
of Blakeley and Meyerzon. However, Appellants respectfully submit that Blakeley and 
Meyerzon (alone or in combination) fail to cure the exemplary deficiencies of Pereira 
and Carper, as set forth above in Section Vlll(l), for claims 1 , 9 arid 17. Consequently, 
claims 6, 14 and 22 are patentable over a reasonable combination, if any, of Pereira, 
Carper, Blakeley and Meyerzon, at least by virtue of their dependency. Furthermore, for 
at least the reasons set forth above in Section Vlll(1 ) for claims 1 , 9 and 1 7, and in 
addition to the disparate teachings of Blakeley and Meyerzon, Appellants submit that 
the Examiner fails to provide any reasonable suggestion or motivation, absent 
impermissible hindsight, for combining Pereira, Carper, Blakeley and Meyerzon in the 
manner proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1, 9, and 17. Since the 
responses to the first seven arguments have established that the combination of Pereira 
and Carper has rendered obvious the independent claims 1 , 9, and 1 7, there is no 
additional requirement for Meyerzon to render obvious these independent claims. The 
response to the eleventh argument has already shown that Blakeley is not required for 
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these claims. It would have been obvious to one ordinarily skilled in the art at the time of 
the invention to drop tables created by users during the current session at the time of 
system shutdown in order to return the table structure of a database to its condition 
before the start of the session. All data in volatile memory is lost at system shutdown. A 
relational database stores information about all database tables on disk regardless of 
whether the tables reside in memory or on the disk. If the tables in memory were not 
dropped at system shutdown, information about non-existent tables would still remain in 
the database at that time. Since no arguments for claims 6, 14, and 22 have been 
provided other than their dependence on independent claims 1, 9, and 17, these claims 
are still rendered obvious. 

11.13 In the thirteenth argument for claims 7, 15, and 23 on page 18, paragraph 
3 and page 19, paragraph 1, the applicants state: 

"In rejecting claims 7, 15 and 23 under 35 U.S.C. § 103(a), the Examiner relies on a 
combination of Pereira and Carper, as applied to claims 1 , 9 and 17, and further in view 
of Benedikt. However, Appellants respectfully submit that Benedikt fails to cure the 
exemplary deficiencies of Pereira and Carper, as set forth above in Section Vlll(1), for 
claims 1, 9 and 17. Consequently, claims 7, 15 and 23 are patentable over a reasonable 
combination, if any, of Pereira, Carper and Benedikt, at least by virtue of their 
dependency. Furthermore, for at least the reasons set forth above in Section Vlll(1 ) for 
claims 1 , 9 and 17, and in addition to the disparate teachings of Benedikt, Appellants 
submit that the Examiner fails to provide any reasonable suggestion or motivation, 
absent impermissible hindsight, for combining Pereira, Carper and Benedikt in the 
manner proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1, 9, and 17. Since the 
responses to the first seven arguments have established that the combination of Pereira 



and Carper has rendered obvious the independent claims 1 , 9, and 17, there is no 
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additional requirement for Meyerzon to render obvious these independent claims. The 
response to the eleventh argument has already shown that Benedikt is not required for 
these claims. It would have been obvious to one ordinarily skilled in the art at the time of 
the invention to provide a syntax in order to provide the users with means of submitting 
queries to the databases. A syntax used when submitting queries to a relational 
database is an inherent property of any relational database. Since no arguments for 
claims 7, 15, and 23 have been provided other than their dependence on independent 
claims 1, 9, and 17, these claims are still rendered obvious. 

1 1 .14 In the fourteenth argument for claims 76, 78, and 80 oh page 19, 
paragraph 3, the applicants state: 

"in rejecting claims 76, 78 and 80 under 35 U.S.C. § 103(a), the Examiner relies on a 
combination of Pereira and Carper, as applied to claims 1, 9 and 17, and further in view 
of Dugan. However, Appellants respectfully submit that Dugan fails to cure the 
exemplary deficiencies of Pereira and Carper, as set forth above in Section Vlll(1), for 
claims 1 , 9 and 17. Consequently, claims 76, 78 and 80 are patentable over a 
reasonable combination, if any, of Pereira, Carper and Dugan, at least by virtue of their 
dependency, as well as the additional features set forth below. Furthermore, for at least 
the reasons set forth above in Section Vfll(1 ) for claims 1, 9 and 17, and in addition to 
the disparate teachings of Dugan, Appellants submit that the Examiner fails to provide 
any reasonable suggestion or motivation, absent impermissible hindsight, for combining 
Pereira, Carper and Dugan in the manner proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1 , 9, and 17. Since the 
responses to the first seven arguments have established that the combination of Pereira 
and Carper has rendered obvious the independent claims 1, 9, and 17, there is no 
additional requirement for Dugan to render obvious these independent claims. Claims 
76, 78, and 80 are essentially restatements of claims 5, 1 3, and 21 . A user specifying 
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the removal of a database table is essentially the same as dropping an in-memory 
database table upon receipt of a drop table command. Since Pereira teaches the 
dropping of a database table at col. 4, lines 7-9 there is no requirement for the Dugan 
reference. Since claims 76, 78, and 80 are dependent on independent claims 1, 9, and 
17, these claims are still rendered obvious. 

11.15 In the fifteenth argument for claims 77, 79, and 81 on page 19, paragraph 
3, the applicants state: 

"In rejecting claims 77, 79 and 81 under '15 U.S.C. § 103(a), the Examiner relies on a 
combination of Pereira and Carper, as applied to claims 1 , 9 and 17, and further in view 
of Farrell. However, Appellants respectfully submit that Farrell fails to cure the 
exemplary deficiencies of Pereira and Carper, as set forth above in Section Vlll(1 ), for 
claims 1, 9 and 17. Consequently, claims 77, 79 and 81 are patentable over a 
reasonable combination, if any, of Pereira, Carper and Farrell, at least by virtue of their 
dependency, as well as the additional features set forth below. Furthermore, for at least 
the reasons set forth above in Section VII 1(1) for claims 1 , 9 and 17, and in addition to 
the disparate teachings of Farrell, Appellants submit that the Examiner fails to provide 
any reasonable suggestion or motivation, absent impermissible hindsight, for combining 
Pereira, Carper and Farrell in the manner proposed." 

The Examiner disagrees. The Applicants have argued that the combination of Pereira 
and Carper has not rendered obvious the independent claims 1 , 9, and 17. Since the 
responses to the first seven arguments have established that the combination of Pereira 
and Carper has rendered obvious the independent claims 1 , 9, and 17, there is no 
additional requirement for Farrell to render obvious these independent claims. It would 
have been obvious to one ordinarily skilled in the art at the time of the invention to 
persistently have tables remain in memory after access by one user for access by 
another user in order have rapid access to the data in these tables and not waste 
overhead between accesses of data. Claims 77, 79, and 81 are essentially 
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restatements of claims 4, 12, and 20. The allowing multiple users to share access to the 
in-memory database table is essentially the same as having the data available for 
access by a second user after it has been accessed by a first user. The allowing of 
access to databases by multiple users in order to modify the database as long as the 
modifications are independent from one another is an inherent feature of rational 
databases. 

For the above reasons, it is believed that the rejections should be sustained. 



Harold E. Dodds, Jr. 
Patent Examiner 
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